-
Notifications
You must be signed in to change notification settings - Fork 13.4k
modularize the config module bootstrap #141272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modularize the config module bootstrap #141272
Conversation
This PR modifies If appropriate, please update |
This comment has been minimized.
This comment has been minimized.
6a1e868
to
b8374d6
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the general direction of this. Could you perhaps split the changes into multiple commits though? It would be easier to review. Thank you :)
b8374d6
to
ad21211
Compare
Kind of crazy just how much code is there in config definition and parsing. The changes LGTM, but since this is a large-ish change, I'd like to hear also from other members of t-bootstrap if they are OK with it. CC @onur-ozkan @jieyouxu. |
@rustbot author |
Reminder, once the PR becomes ready for a review, use |
cc @clubby789 |
@rustbot review |
Vibes-wise, organization seems fine to me. |
I still have this concern (also see this as an additional ref). With the current approach, adding new things will always be unclear for some people. Even now, for example, we have What I would suggest instead is organizing the modules based on the configuration field. For example, With this structure it would make it very explicit where things belong and anything that doesn't fit this rule can be easily caught during PR reviews. |
This comment has been minimized.
This comment has been minimized.
2dc25e6
to
877aa18
Compare
1ec9ad3
to
6ec7ec9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you so much for looking into this!
Do you have any concerns on the current state of this PR? I don't want to r+ without your approval since you were the main reviewer. @Kobzol |
No, I'm good. Thank you, great work! @bors r+ |
…onfig-module, r=Kobzol modularize the config module bootstrap Currently, our `config` module is quite large over 3,000 lines, and handles a wide range of responsibilities. This PR aims to break it down into smaller, more focused submodules to improve readability and maintainability: * **`toml`**: Introduces a dedicated `toml` submodule within the `config` module. Its sole purpose is to define configuration-related structs along with their corresponding deserialization logic. It also contains the `parse_inner` method, which serves as the central function for extracting relevant information from the TOML structs and constructing the final configuration. * **`rust`, `dist`, `install`, `llvm`, `build`, `gcc`, and others**: Each of these modules contains TOML subsections specific to their domain, along with the logic necessary to convert them into parts of the final configuration struct. * **`config/mod.rs`**: Contains shared types and enums used across multiple TOML subsections. * **`config/config.rs`**: Houses the logic that integrates all the TOML subsections into the complete configuration struct. r? `@kobzol`
Rollup of 8 pull requests Successful merges: - #140638 (UnsafePinned: also include the effects of UnsafeCell) - #141272 (modularize the config module bootstrap) - #141777 (Do not run PGO/BOLT in x64 Linux alt builds) - #141870 (Fix broken link to rustc_type_ir module in serialization docs) - #141938 (update rust offload bootstrap) - #141962 (rustc-dev-guide subtree update) - #141965 (`tests/ui`: A New Order [3/N]) - #141970 (implement new `x` flag: `--skip-std-check-if-no-download-rustc`) r? `@ghost` `@rustbot` modify labels: rollup
6ec7ec9
to
3667dbd
Compare
Hmm, we should probably run @bors r+ rollup=iffy |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing cf42371 (parent) -> d00435f (this PR) Test differencesNo test diffs found Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard d00435f223dc3a88d8c5f472b10ba948b7959cc6 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Currently, our
config
module is quite large over 3,000 lines, and handles a wide range of responsibilities. This PR aims to break it down into smaller, more focused submodules to improve readability and maintainability:toml
: Introduces a dedicatedtoml
submodule within theconfig
module. Its sole purpose is to define configuration-related structs along with their corresponding deserialization logic. It also contains theparse_inner
method, which serves as the central function for extracting relevant information from the TOML structs and constructing the final configuration.rust
,dist
,install
,llvm
,build
,gcc
, and others: Each of these modules contains TOML subsections specific to their domain, along with the logic necessary to convert them into parts of the final configuration struct.config/mod.rs
: Contains shared types and enums used across multiple TOML subsections.config/config.rs
: Houses the logic that integrates all the TOML subsections into the complete configuration struct.r? @Kobzol